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Abstract: 


Ensuring security for highly dynamic peer-to-peer (P2P) networks, critical 
for services like online transactions and smart devices, has always been a 
significant challenge. Adding to this dynamism and very high churn rates is 
their uniqueness in access control compared to traditional systems, 
particularly Role-Based Access Control (RBAC). This thesis contributes 
toward a new access control framework for blockchain-based systems using 
Ethereum smart contracts. The framework contributes toward closing the 
gap in existing systems with flexible, transparent, and decentralized 
security solutions. The contract framework we propose has access control 
contracts (ACCs) that protect access through static and dynamic policies, a 
Judge Contract (JC), and a Register Contract (RC) that records ACCs and JC 
for the purpose of their interactions. Its security model incorporates impact 
and severity-based assessment of the threats by using the CIA 
(Confidentiality, Integrity, Availability) and STRIDE principles, whose result 
will be responses tailored to the threats. The system does not only mitigate 
the fundamental volatility of peer membership but provides a scalable 
solution, which could be of high value, notably in areas like the Internet of 
Things (loT) and Web 3.0 technologies. 


1. Introduction 


The introduction of peer-to-peer (P2P) networks has been very essential to 
decentralized service distribution, including services such as online 
transactions and content sharing or interconnectivity of intelligent devices. 
However, despite their great usefulness, P2P networks face the whole scale 
of fundamental security challenges that are topped up by the high churn of 
members and their structural openness. Usually, these challenges of the 
system come in the following form of threats under the STRIDE model: 
Spoofing, Tampering, Repudiation, Information Disclosure, Denial of 
Service, Elevation of Privilege—all serious risks to the confidentiality, 
integrity, and availability. 


Traditional access control models, such as Role-Based Access Control 
(RBAC), have  insufficiencies in managing the dynamism and 
decentralization that characterize P2P networks, and hence, give rise to 
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serious trust issues among the parties of a network. Most of the time, these 
trust issues arise mostly due to a lack of centralized authority. This would 
ensure that there is an existence of some form of an authority that ensures 
all participants are authenticated to perform tasks within the network and 
given permission to do so in the right manner, and that their actions within 
the network are accountable. 


In this work, we introduce a blockchain-based framework for access control 
to address these challenges by using the natural characteristics of 
blockchain technology, which comprise immutability, transparency, and 
decentralization. Our RC-based architecture uses a two-level hierarchy, 
which can ensure efficient data lookup and, consequently, minimizes latency 
in communication. At level 1, a group head (Gh i) is connected with an 
optimization for data routing structure. At level 2, there are fully connected 
groups of peers, where each group (Gi) is attached to the transit network 
through its group head (Gh i). In a fully interconnected network, therefore, 
groups communicate between themselves and never to the transit network. 
The architecture proposes the access control through the powerful 
Ethereum Smart Contract framework and integration of it into the 
framework makes it a trustless environment, so it can enforce and 
acknowledge valid security policies that do not require central authority 
intervention and, therefore, mitigate existing possible security threats. 


1.1 Motivation 


The motivation of this research is the current gaps in traditional methods 
that offer a scalable and adaptive way for the access control to state-of-the- 
art (SoA) consensus security mechanisms within P2P networks. This 
proposed system, based on blockchain, aims at bridging these gaps with 
further enhancement of the overall infrastructure of security, allowing much 
stronger and reliable network interactions. 


1.2 Problem Statement 


Peer-to-peer (P2P) networks face significant security challenges due to their 
decentralized nature and high member turnover. Very often, traditional 
control systems like RBAC (Role-Based Access Control) very often leave 
security loopholes wide open for unauthorized access and possible data 
breaches, precisely because they fail to be applied in a network 
Management scenario that is dynamic. In essence, this research will cater 
to a critical need for a flexible, scalable trustless security framework in P2P 
networks, whose aim is to mitigate a range of dynamic security threats for 
enhanced decentralized operational integrity, while at the same time 
ensuring sophisticated communication among the network architecture, 
access control, Web 3.0 ethos, and the strengths of blockchain. It can be 
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positioned in the transformational landscape of the distributed 
infrastructure and web 3.0, which indicates cybersecurity challenges. 


1.3 Research Questions 


1. How can blockchain technology be used to address the inherent 
security vulnerabilities in peer-to-peer (P2P) networks, particularly 
regarding access control? 


2. In what ways do Ethereum smart contracts be used in the 
implementation of access control mechanisms in P2P networks 
compared to traditional access control models? 


3. How does the proposed blockchain-based access control framework 
ensure dynamic and static policy management within P2P networks, 
and what are its effects for network security? 


2. Literature Review: 


2.1 Related Research on Peer-to-Peer Security in General 

The need for robust security frameworks in IoT environments is critical. 
Novo (2018) proposed scalable blockchain architecture for the access 
management of IoT, presenting the nature of blockchain that can provide 
better security for the systems and bring about efficacy in their operations. 
Going further than that, Yu, Chen, and Wang (2022) discuss other layers of 
security challenges, like those represented by latency and node 
heterogeneity problems, including in distributed networks. Now, 
respectively, Mbarek, Ge, and Pitner (2020) apply those same concepts to 
smart home, smart grid systems, showing how data integrity and resilience 
of blockchain towards cyber-attacks significantly increase for these special 
applications within peer-to-peer networks. [1][3][12][18]. 


2.2 Blockchain in Peer-to-Peer Networks 

Sun et al. (2022) critically reviewed the role that blockchain plays in IoT, 
with a great focus on how it can revolutionize access control across 
different sectors by using smart contracts with improved transparency. 
Complementing this, Ding et al. (2019) provide an attribute-based access 
control scheme minimizing overhead, enhancing security, and proofing real- 
world practicability. Similarly, Wang et al. (2022) proved their development 
—a dynamic access control system that will adapt to the changes in user 
behavior and the status of his devices in real-time—stressing the flexibility 
of blockchain solutions under a complex network environment [2][16][19]. 


2.3 Access Control in Peer-to-Peer Networks 
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On the other hand, another scope of Liu et al. (2020) related to the 
integration of blockchain in IoT networks is its great impact on enhancing 
access control mechanisms, thus reducing the risks brought by 
unauthorized accesses and breaches. Furthermore, Sultana et al. (2020), 
Badhe and Arjunwadkar (2023) provided the most insightful practical 
examples with regard to these themes: detailed and analyzed practical 
examples of how blockchain-based smart contracts find application, 
enabling secure and efficient access control systems for data sharing and 
data distribution. It draws an apt example of scalability and adaptability, 
important for contemporary IoT frameworks [8][11][13][15][17]. 


2.4 Integration of Access Control, Peer-to-Peer, and Blockchain 
Collaboration with the access control system through the blockchain model 
to peer-to-peer networks is a strong solution against IoT security. Zhang et 
al. (2020) have elaborated a critical evaluation of the different blockchain- 
based models and scope on the key conditions of improvement for the 
scalability and security concerns. Han et al. (2022) and Li et al. (2021) 
further elaborated with an audit dual-layer scrutinization of the blockchain 
system to possibly manage access controls more efficiently, which 
consequently enhances a better reality of reliability and flexibility in 
operations. Such developments would be critical in moving forward towards 
more sophisticated and robust IoT architectural designs that can handle the 
dynamic and complex nature of modern network interactions [5][6][7][9] 
[10][14][20] 


3. Methods 
3.1 Design Philosophy 


Access Control Process Flow The process flow for access control in the 
proposed system is as follows: 
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3.2 Smart Contract System 
3.2.1 Access Control Architecture 


Lookup Table 


Misbehaviour Report 


Penalty Decision 


The proposed framework consists of multiple access control contracts 
(ACCs), and each implements the access control for a pair of peers a.k.a. 
one subject and one object. And there are one judge contract (JC), which 
takes the misbehavior report of a peer from an ACC, judges the misbehavior 
and determines the corresponding penalty, and one register contract (RC), 
which stores the information of the JC and ACCs and provide functions to 
manage these contracts and as well, stores every log event data to help the 
JC impose penalty. 


3.2.2 Access Control Contracts (ACCs) 
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At the core of the framework, designed to secure peer-to-peer (P2P) 
networks, are the Access Control Contracts (ACCs), as illustrated in Figure 
3. These contracts, such as ACC 1, ACC 2, and ACC 3, are deployed by a 
peer (the object) who seeks to regulate access requests from another peer 
(the subject). It's an approach where the control of access is managed 
between the subject and object peers and each ACC is exclusively dedicated 
to one specific pair, ensuring a tailored and secure access control 
mechanism. 


Each ACC operates on a dual validation system, where necessary, to 
Manage access requests from the subject peer effectively. The first layer, 
Fixedrule access control protocol, where static access right validation, 
inspects access requests against a set of predefined policies to ensure they 
comply with established permissions. The dynamic layer of validation takes 
this a step further by observing the subject's behavior in real-time. This 
allows the system to adaptively manage access based on current activities, 
enhancing security against potential threats or abuse. 


full (view, full (view, full (view, full (view, Other group 
edit, create, edit, create, edit, create, edit, create, head 


delete) delete) delete) delete) own members 


own group head 
view view view, edit deny 
own members 


own members 
deny view deny deny 
own group head 


An illustrative example of how an ACC functions can be understood through 
its management of a policy list. This list acts as the backbone of the ACC, 
where each entry delineates a policy for a specific resource-action pair. 
Here's a glimpse into what such a policy list might look like, adapted to 
reflect a more comprehensive and role-specific scenario: 
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Permissi 


Role Resource Action on ToLR 
Primary GroupGlobal Resource 2023-04-01 
Head Table Edit allow 10:00:00 
Primary GroupLocal Resource 2023-04-01 
Head Table delete allow 10:00:00 
Regular Communication with Own 2023-04-01 
Members Access Group Head allow 10:00:00 
Regular Local Resource 2023-04-01 
Members Table delete deny 10:00:00 
Secondary Global Resource 2023-04-01 
Group Head Table edit deny 10:00:00 
Secondary Local Resource 2023-04-01 
Group Head Table view allow 10:00:00 


This example list log data for various actions on resources, defined by the 
role of the peer. Overall, this setup serves as the foundation for static 
validation by outlining whether a specific action on a resource is allowed or 
denied. The "Time of Last Request (ToLR)" field adds a dynamic aspect to 
the validation process, enabling the ACC to monitor and control access 
based on the recency of requests, thereby preventing potential misuse 
through too frequent access requests in a short timeframe. 


Furthermore, the ACC maintains a misbehavior list for each resource. This 
list records any deviations from acceptable behavior by the subject, the time 
of occurrence, and the penalties imposed. Such meticulous record-keeping 
strengthens the framework's ability to dynamically adjust access 
permissions and enforce discipline within the P2P network. 

3.2.2.1 Dynamic Validation Policies with Flexicheck Access Control 
Protocol 


This table presents a range of security policies designed to protect IoT 
systems by dynamically responding to different types of security violations. 


Severi STRIDE 
Security Event ty CIA Impact Impact Response 
Too many Elevation of 
Access Attempts High Integrity Privilege 24-hour ban 
Cancel access 
privileges 


Data Tampering High Integrity Tampering permanently 


Unauthorized Mediu ConfidentialitInformation Temporary 
Access tom y Disclosure suspension of 
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Severi STRIDE 


Security Event ty CIA Impact Impact Response 
Restricted access rights for 7 
Operations days 

30 days 

suspension, 
Disruption of Denial of possible legal 
Service High Availability Service action 

Warning for first 

offense, the 
Misrepresentati Accountabilit penalties for repeat 
on of Identity Low y Spoofing offenses 


To manage these policies and implement the access control, the ACC offers 
several Application Binary Interfaces (ABIs), including but not limited to, 
policyAdd, policyUpdate, policyDelete, and accessControl. These 
functions enable the ACC to add new policies, update or delete existing 
ones, and execute both static and dynamic validations for access requests. 


e policyAdd(): This ABI receives the information of a new access control 
policy and adds the information to the policy list. 


e policyUpdate(): This ABI receives the information of a policy that needs to 
be updated and updates thepolicy. 


e policyDelete(): This ABI receives the identification information of a policy 
and deletes the policy. 


e accessControl(): This ABI receives the information required for access 
control and returns the access resultand penalty. 


e set/C(): To send the report to JC, ACC needs to have this ABI. 


3.2.3 Judge contract (JC) 


The JC judges the misbehavior of the subject and deter-mines the 
corresponding penalty, when receiving a potential misbehavior report from 
an ACC. After determining the penalty, the JC returns the decision to the 
ACC for further operation. 


e Object: the peer who felt the misbehavior. 
e Misbehavior: the details of the misbehavior. 
e Time: the time when the misbehavior is exhibited; and 


e Penalty: the penalty imposed on the misbehavior. 
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resource 


Subject Object Misbehavior Penalty 
Primary Group Local Unauthorized | Blocked 2 hours 
Head 1 Resource Table | edit 
Primary Group Global Excessive | Blocked 1 day 
Head 2 Resource Table | deletion 
Secondary Group Malicious | False report Blocked 3 hours 
Head Member 
Primary Group Secondary | Unauthorized | Warning issued 
Head 3 Group Head's | access 
member 
Secondary Group | Primary Group Data | Blocked 5 hours 
Head Head's tampering 


Regular Member 


Local 
Resource Table 


Data scraping 


Blocked 2 days 


The JC will have the following ABIs for judging misbehavior: 


e misbehaviorJudge(): This ABI will be run by any ACC to report the 
misbehavior of a subject to the JC. After receiving the report, this ABI 
judges the misbehavior of the subject, determines the penalty on the subject 
and returns the penalty decision to the ACC. This ABI also adds a new 
misbehavior record to the list. 


3.2.4 Register contract (RC) 


The RC will maintain a lookup table, which registers the information to find 
and execute all the methods. An example: 


e MethodName: the name of the method; 


e Subject: the subject of the corresponding subject-object pair of the 
method; 


e Object: the object of the corresponding subject-object pair of the method; 


e ScName: the name of the corresponding smart contract implementing this 
method; 


e Creator: the peer who created and deployed the contract; 


e ScAddress: the address of the smart contract; and 
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MethodName Subject 


Primary 
viewGlobalRes Group 


Object ScName ScAddress ABI 


Global Primary 


Resourc Group Head AccessControl 


ource Head e Table Role ACC 0x123...def () 

Primary Local Primary 
viewLocalReso Group Resourc Group Head AccessControl 
urce Head e Table Role ACC 0x123...def () 
communicate Primary Regular 
WithOwnGrou Regular Group Members AccessControl 
pHead Member Head Role ACC 0x456...ghi () 

Secondary Global Secondary 


AccessControl 
0x789...jkl () 


viewGlobalRes Group 
ource Head 


Resourc Group Head 
e Table Role ACC 


With the help of the lookup table, the RC provides the following main ABIs 
to mange these methods. 


e methodRegister(): This ABI receives the information of a new method and 
registers the information into the lookup table. 


e methodUpdate(): This ABI receives the information of an existing method 
that needs to be updated and up-date the information, especially the fields 
of ScAddress and ABI. 


e methodDelete(): This ABI receives the MethodName of a method and 
deletes the method from the lookuptable. 


e getContract(): This ABI receives the MethodName of a method and 
returns the address and ABIs of the contract (i.e., the ACCs and JC) of the 
method. 


3.2.5 Threat Model 


We also adopted a threat model that studies the vulnerabilities of the group 
heads that relate to the challenges for data integrity. It assumes a scenario 
where compromise to a primary group head takes place due to malicious 
activities, in which case a secondary group head will be maintaining the 
integrity of inter-group communications. 
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3.2.6 Communication Simulation 
3.2.6.1 Dynamic Reference Passing 


Beyond maintaining the lookup table, the RC is also engineered to 
dynamically provide reference data to different roles within the network 
based on their needs. For instance: 


e When a Primary Group Head acts as the subject and requests 
access to a resource or interaction, the RC supplies the reference 
data, such as the "Primary Group Head Role ACC," to facilitate the 
access or communication. 


e Similarly, if a Secondary Group Head or Regular Member assumes 
the role of the subject, intending to connect with a resource or 
another entity, the RC provides them with their respective ACC 
references, like "Secondary Group Head Role ACC" or "Regular 
Members Role ACC," accordingly. 


Subject Role Reference Data 
Supplied by RC 
Primary Group Primary Group Head 


Head Role ACC 

Secondary Secondary Group Head 
Group Head Role ACC 

Regular Regular Member Role 
Member ACC 


This dynamic reference mechanism ensures that each peer, depending on 
their role and the nature of the access request, is equipped with the 
appropriate smart contract references. It facilitates a fluid and secure 
interaction within the network, ensuring that access controls are adhered 
to, and that the P2P ecosystem operates within the bounds of predefined 
policies and permissions. Through this sophisticated orchestration, the RC 
significantly enhances the network's security, reliability, and efficiency. 


3.2.6.2 Workflow Diagram 


In our blockchain-based system, the communication between primary group 
heads (PGHs) is efficiently managed through a series of interactions with 
smart contracts, specifically the Registry Contract and the Primary Group 
Head Role Access Control Contract (ACC). These interactions ensure secure 
and verified communications within the network. Detailed steps of the 
communication process are fully illustrated in the accompanying diagrams, 
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which depict how access requests are handled, 


maintain network security and integrity. 


PGH1 


“Registry Contract" "Primary Group Head Role ACC" 


Step 1: Initiate communication request 


Step 2: Pass reference data [Primary Group Head Role ACC] 


Step 3: Send access request 


validated, and logged to 


PGH2 “Judge Contract JC)" 


Step 4: Execute communicateWithGroupHead() 


> 


Establish communication channel 


Step 5: Send success report 


Step 8: Return access result 


> 


Step 6: Save log of communication 


Step 7: Pass green signal 


PGi a e e a a E E 
Communication established 
PGH1 "Registry Contract" "Primary Group Head Role ACC" PGH2 “Judge Contract (JC)" 
PGH1 “Registry Contract "Primary Group Head Role ACC" PGH2 ‘Member of PGH2's Group" ‘Judge Contract JC)" 
n request 
> 
ep 2: P: fe data [F oup Head Role ACC] 
< p 
Step 3: Send access request 
> 
Step 4: Execute communicateWithGroupHead() 
tep 5: Send success rep rt 
> 
log of communicati 
ie) 
Step 
Pe is 
Step 8: Return a it 
Step 9: Request to t 
> 
Step 10: Validate member 
See 
Acknowledge 
ge ed 
Con 
< 
Step 11: Direct cor ication 
> 
Communication via PGH2 
PGH1 “Registry Contract "Primary Group Head Role ACC" PGH2 Member of PGH2's Group" Judge Contract JC)" 


In the blockchain-based access control system, 


the architecture is 


meticulously structured to ensure that updates and deletions of Access 
Control Contracts (ACCs) or their methods are strictly regulated. This 
structured approach ensures that any changes made are in line with the 
overarching system's integrity and security standards. 


Operational guidelines are put in place to manage these updates effectively. 
Fach change to access control methods or policies requires a thorough 
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review process to confirm its alignment with the system's predefined roles 
and architecture. This ensures that modifications do not compromise the 
network’s security or functionality. 


Both the Register Contract (RC) and Judge Contract (JC) are instrumental in 
Maintaining the integrity of the system. They oversee the application of 
policies and the execution of roles within the network, particularly ensuring 
that primary group heads (PGHs) can interact seamlessly and securely. This 
oversight helps tailor access control mechanisms to meet the specific needs 
of the network’s architecture, enhancing both communication and 
operational efficiency across the platform. 


3.3 Smart Contract Implementation 
3.3.1 Specifications of Devices 


This section provides in implementation to demonstrate the application of 
the proposed framework for distributed access control. We first introduce 
the hardware and software used in the study and then present how the 
access control is implemented based on the framework. 


Hardware used in this implementation: 


Devic | CPU Operating Memo | Storage 

e System ry 

HP Processor Intel(R) Core(TM) | Microsoft 15.9 HDD: 931.51 
Proboo | i7-7500U CPU @ 2.70GHz, | Windows 11 | GB GB 

k G4 2904 Mhz, 2 Core(s), 4 | Pro (64 bit) SSD: 223.57 
440 Logical Processor(s) GB 


3.3.2 System Implementation 


1. Access Control Contracts (AccessControlContracts.sol): Defines 
roles and permissions for different group members, implementing 
functions for resource access and management. 


Algorithm AccessControl 

NormalPrimaryGH(resourceTable) { 

if resourceTable == ("Global Resource Table", "Local Resource Table): 
return “Full access: view, edit, create, delete” 
NormalSecondaryGH(resourceTable) { 

if resourceTable == ("Global Resource Table", "Local Resource Table) 
return view 
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NormalRegularMember(resourceTable) { 


if resourceTable == ("LocalResource Table"): 
return view 
else resourcelable == ("Global Resource Table"): 


return deny 
End Algorithm 


Figure: In figure 3, we observe the execution of a contract named 
"PrimaryGroupHeadRoleACC." This contract is tasked with managing 
communications between group heads. It demonstrates a transaction 
initiated from a specific Ethereum address, signaling an attempt to invoke 
the method communicateWithGroupHead. The transaction incurs a gas cost, 
which is the fee for the computational effort needed to execute the 
operation—denoted as 188 gas units in this case. Gas costs are only 
applicable when functions are called by a contract. The screenshot also 
shows the input data along with decoded input, output, and logs, which 
collectively confirm the successful execution of the contract's function. 


a> DEPLOY & RUN TRANSACTIONS 


Jeployed Contracts 


2. Group Management Contracts (GroupContracts.sol): Manages 
group members and resources, with functions for adding peers and 
assigning resources. 


Algorithm GroupContract 
- Initialize group with a head and public key 
- addPeer(peerAddress, publicKey) : 
IF called by group head THEN 
Add peer to group 


Page 14 


ENDIF 
- addResource(peerAddress, resourceName) : 
IF called by group head THEN 
Assign resource to peer 
ENDIF 
End Algorithm 


Figure: Implementation illustrated in Figure 4. 


D DEPLOY & RUN TRANSACTIONS Ba Oa Ba a A Home ct Restore Backup Zip $ GroupContractsol X 
Ww = EY 
NVI NMEN y 
pragma solidity 40.8.0; 
Remix VM (Cancun) 


wm contract GroupContract StructDefinition 


UNT @ ddr 
0x5B3...eddC4 (100 ether) Og ytes publickey; 


contracts/GroupContract.sol 4:4 


struct Resource { 
string resi c 


1 
5 


mapping(address = 
mapping(addres ) resources; 
address re 


GroupContract - contracts/GroupCon> 


Deploy 
modifier pHead() { 


Publish to IPFS F 
ender == groupHeadAddress, 


} 
5 


function addPe peer: ress, t _ pub. Key b onlyGroupHead { E infinite gas 
peers[_pee >(_peerA SS, _publicKey) 


3. Judicial System Contracts (JudgeContracts.sol): Handles security 
events and imposes penalties based on misbehaviors, crucial for 
enforcing the network's access control policies. 


Algorithm JudgeContract 
- Define security events and corresponding penalties 
- imposePenalty(subject, eventType): 
IF eventType detected THEN 
Log event and apply penalty (temporary or permanent) 
ENDIF 
End Algorithm 


Figure: In the figure 5, we have "JudgeContract," which empowers the 
network with the ability to impose penalties. The left panel displays an 
interface for imposing penalties, where a specific address, identified as the 
subject of the penalty, can be targeted. The penalties are defined within the 
contract and can be executed through its ABI, reflecting the Judge 
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Contract's crucial role in maintaining order and enforcing rules within the 
network. 


DEPLOY & RUN TRANSACTIONS > r l © JudgeContractsol X $ 
viewGlobalRe... 


viewLocalRes... 


Low level interactions 


Infrastructure Support Contracts: 


4. Registry System (RegisterContracts.sol): Maintains a 
comprehensive registry of all contracts, enhancing the interaction and 
lookup processes within the network. 


Algorithm RegisterContract 
- registerMethod(methodName, details): 
Add contract method details to registry 
- getContractInfo(methodName) : 
Return contract method details from registry 
- callRegisteredMethod (methodName) : 
Dynamically call a method from the registered contract details 
End Algorithm 


Figure: "RegisterContract," illustrated in the figure 5, which maintains the 
registry of all methods and associated contracts within the network. With 
functionalities such as registerMethod, getMethod, and 
registerContractInfo, the Register Contract serves as a directory service, 
enabling dynamic linking between contracts and methods. It ensures that 
interactions between different network entities are conducted seamlessly 
and securely. 
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DEPLOY & RUN TRANSACTIONS > a tract. $ JudgeContrac © RegisterContractsol X $ 


5. Network Structure and Resource Management: 


¢ Resource Table (ResourceTable.sol): Manages a local 
resource table for each peer, crucial for resource allocation 
within groups. 


¢ Transit Ring Network (TransitRingNetwork.sol): Facilitates 
efficient data lookup and inter-group communication through a 
managed ring network of group heads. 


Algorithms: ResourceTable and TransitRingNetwork 


Algorithm ResourceTable Algorithm TransitRingNetwork 
- Initialize group with a - Initialize empty ring network of group 
head heads 
- addResource(peerAddress, - addGroupHead(groupHeadAddress, 
resourceName) : publicKey) : 

IF called by group head Add new group head to the ring, link to 
THEN next 


Add resource to peer's | - getNextGroupHead (groupHeadIndex) : 
local resource table Return next group head in the ring 
ENDIF -updateGroupHeadPublicKkey (groupHeadIndex, 
End Algorithm newPublickey) : 
Update group head's public key if 
called by the group head itself 
End Algorithm 
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Figure: "TransitRingNetwork," which lays the foundation of our P2P 
architecture. This contract allows for the addition and updating of group 
head information, facilitating the expansion or alteration of the network's 
structure. While the current architecture is set, these functionalities hint at 
future potential for network growth or reconfiguration. 


w DEPLOY & RUN TRANSACTIONS s t ct.sol RegisterContract.so Resource Tables.so $ TransitRingNetwork.sol 
v e rac i 


Low level interactions 


mapping(uint = ead) groupHeads; 


uint 


mapping(uint = 
mapping(uint = 


function addGr addre roupHead s t _publicKey) 
getNextGroup... 


groupHeadAd... 


groupHeadCo... 


groupHeadPu... 


groupHeads 


Low level interactions 


Figure: "ResourceTable,” allows deploying the group head address, 
facilitating information sharing within of the permitted network's structure. 
While the current architecture is set, these functionalities hint at future 
potential for network growth or reconfiguration. 


D DEPLOY & RUN TRANSACTIONS > J ne up Zip Gi so & ResourceTables.sol X 
v a 
NT Y 
Remix VM (Cancun) 
vm 
INT @ 


Ox5B3...eddC4 (100 ether) 
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In this implementation, the Ethereum-based Remix Integrated Development 
Environment (IDE) was utilized for the development of smart contracts that 
underpin the access control mechanisms within our peer-to-peer network. 
The Remix IDE enabled the efficient writing, testing, and deployment of 
smart contracts written in Solidity directly onto the Ethereum blockchain. 
The development and testing phases of these contracts were carried out 
within the Remix IDE, which provided an Ethereum node simulation for 
deploying and invoking the smart contracts. This allowed for a thorough 
examination of the contracts’ functionality before being deployed to the live 
network. 


This Ethereum-based implementation leverages the security and 
transparency of blockchain technology while allowing for the complex, rule- 
based access control logic necessary for secure its applications. The 
combination of Ethereum's robust blockchain with the flexible programming 
afforded by Remix and Solidity provides a powerful toolset for realizing 
distributed access control systems in the IoT domain. 


3.4 Future Plan 


This thesis aims to explore innovative blockchain applications, evaluate 
their effectiveness in real-world scenarios, and push the boundaries of 
current access control technologies. 


1. Theoretical Simulation 
Minor Goals: 


¢ (Event 1 - Normal Operation) Without Attack: Simulate the event 
where and check the framework's baseline security in a controlled 
environment. 


¢ (Event 2 - Normal Operation) With Attack but No Access Control: 
Simulate the network's vulnerability to security breaches and the 
effects of such breaches on network. 


«e (Event 3 - Malicious Operation) With Attack but Working Access 
Control: Evaluate the framework's effectiveness in real-time 
misbehavior detection (ACC’s), Impose Penalty (JC) and storing the 
log data of an attack and helping the JC and ACC’s to safeguard their 
responsibility (RC) in the process of mitigating an attack. 


2. Engineered Solution: 


Minor Goals: 
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e Smart Contract for Onboarding: Create a smart contract that 
manages the registration and validation of new peers. This contract 
will require new members to submit cryptographic proof of identity 
and credentials. 


e Validation Protocol: Implement a protocol within the smart contract 
that allows existing network nodes to vote on the admission of new 
peers based on the submitted credentials and a consensus algorithm. 


e Credential Verification: Integrate a cryptographic verification 
mechanism that checks the validity of the credentials against a 
decentralized public key infrastructure (PKI). 


3. Integration of Advanced Blockchain Features 
Minor Goals: 


e Explore the integration of additional blockchain functionalities, such 
as zero-knowledge proofs and sidechains. 


e Develop and test smart contract upgrades that introduce more 
complex rule sets for dynamic access control. 


4. Expansion of the Access Control Framework 
Minor Goals: 


e Design and deploy additional roles and permissions within the 
network to contain more complex structures. 


e Modifying access control contracts to automatically respond to 
common security incidents, in this manner reducing the need for 
manual intervention each time. 


5. Future Directions 
Minor Goals: 


e Explore the use of artificial intelligence (AI) to predict security 
breaches before they occur, through integrating AI with blockchain. 


Page 20 


e Prove the scalable and effective nature of the framework with a real- 
world IoT environment pilot, e.g., in a smart city. 
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